边缘计算南向采集优化方案 — 2026 第三季度

项	内容
版本	V1.0
周期	2026 Q3（7 月 — 9 月）
状态	Q3 收尾中（主体内核已交付，画像闭环与灰度验证进行中）
前置文档	边缘计算南向采集优化方案2026第二季度.md
架构总览	边缘网关架构设计总览.md
当前状态	ROADMAP.md · DEVELOPMENT_PRINCIPLES.md
对标基准	行业标准软件 — Tag Database · Scan Class · Block I/O · Publish Rate · Store & Forward · Diagnostics

1. 文档目的

Q2 完成了 ScanEngine 调度驱动内核（ExecutionLayer + ResourceController + 调度闭环）、ShadowCore 影子快照、RTT/MTU/Gap 算法模块 的代码交付；Q3 初 ShadowBridge → DataPipeline 扇出 与 finalizeScanCollect 状态回写 已落地，但 画像读路径闭环、熔断、四阶段灰度运维验证 仍未达到工业级端到端目标。

Q3 目标：从「模块存在」转向 工业采集软件式产品能力闭环 — 统一数据面、可预测调度、块读高吞吐、Tag 级韧性、可运维 Diagnostics。

2. Q2 继承基线（2026-06-25 审查摘要）

2.1 已具备能力

能力	实现位置	说明
ScanEngine 调度驱动内核	`scan_engine.go` + compat	10ms Tick、PriorityQueue、防饿死、Scan Class、调度闭环
ExecutionLayer	`execution_layer.go` 等	Serial 硬隔离 + Parallel 三层背压 + Limited
ConnectionManager	`driver/connection_manager.go`	Modbus/DLT645 已统一；OpcUa/ENIP 待迁移
ShadowCore + ShadowBridge	`shadow_core.go`, `shadow_bridge.go`	纯内存 SoT；`main.go` 扇出至 DataPipeline
配置 DB 单源	`config_store.go` + `config.db`	安装向导、热 CRUD、配置 DB 强一致写入
RTT / MTU / Gap	`rtt_manager.go` 等	算法 + 单测；ExecutionLayer 读路径未系统消费
设备状态闭环	`finalizeScanCollect`	ScanEngine → ChannelManager → FinalizeCollect
边缘规则引擎	`edge_compute_manager.go`	阈值/表达式/窗口；经 Pipeline 触发（ShadowBridge 已挂载）
VirtualShadow	`virtual_shadow_engine.go`	公式依赖图
多协议南向	`internal/driver/*`	Modbus / OPC UA / BACnet / S7 / EIP / Omron FINS / DLT645 等
ModbusDriver	`modbus.go`	纯执行 + Transport；Gap 读分片未联动

2.2 核心断层（Q3 必须解决）

ScanEngine → ExecutionLayer → Driver → ShadowCore → WebSocket  ✓
                              ↓
                    ShadowBridge → DataPipeline  ✓（main.go 已挂载）
                              ↓
              EdgeCompute / Northbound / 历史  ✓（主路径已通）

剩余差距（对照 ScanEngine重构方案.md §9）：

RTT/Gap 画像未驱动 ExecutionLayer 块读分片
ScanEngine Execute 后未系统 UpdateDeviceRTT
OpcUa/ENIP 重连未统一 ConnectionManager single-flight
熔断机制、DRY_RUN 四阶段灰度运维验证未做
边缘规则 Window/RuleState 与影子强一致、高压背压策略待验收

2.3 Q2 未交付项（Q3 承接）

项	Q2 状态	Q3 归属
点位降级框架	❌	Q3-C
RTT/MTU/Gap UI	❌	Q3-C
Gap → Modbus 块读	🟡	Q3-B
ScanEngine → UpdateRTT	🟡	Q3-B
100k 点/秒压测	❌	推迟 Q4；Q3 做 1w Tag 基线
智能心跳 / HAL / Ring Buffer	❌	不做

3. Q3 总目标

统一数据面：Shadow 为运行时真源（SoT），Pipeline 为扇出，北向/边缘/历史与 UI 一致。
可预测调度：Scan Class + 调度 SLA 可观测；工业模式可关闭失败退避。
高吞吐 I/O：Modbus/OPC UA 块读闭环，输出万 Tag 压测基线报告。
Tag 级韧性：点位降级与指数探测恢复（补 Q2 缺失）。
可运维：Diagnostics 对标工业采集软件 Statistics / Event Log。

4. 工业采集软件概念映射

工业采集软件概念	工业含义	EdgeX Q3 模块
Tag Database	统一 Tag 名、EU、缩放、别名	`scan_class` 字段 + 后续 TagRegistry
Scan Mode	同步读 / 订阅 / 只读一次	驱动 Capability 标记 + ScanEngine 任务类型
Scan Class	100ms / 1s / 10s 分组扫描	每设备按 Class 多任务调度
Block I/O	寄存器块读、减少报文数	GapOptimizer → ExecutionLayer 分片
Publish Rate	采集频率 ≠ 上报频率	Shadow 全采 + Pipeline 北向限频
Store & Forward	断网缓存、恢复补发	统一 OfflineQueue 策略
Diagnostics	通道/设备/Tag 延迟与错误统计	`/api/diagnostics/*` + 指标
Media Redundancy	主备通道	Q4 设计预留

5. Q3 目标架构

┌──────────────── Tag 配置 (scan_class, interval, EU) ───────────────┐
│                     config.db / Devices bucket                     │
└───────────────────────────────┬────────────────────────────────────┘
                                │
                    ┌───────────▼───────────┐
                    │   ScanEngine（内核）   │
                    │  ScanClass · Priority  │
                    │  ResourceController    │
                    │  Anti-starvation       │
                    │  Metrics (lag/overdue) │
                    └───────────┬───────────┘
                                │ dispatch
                    ┌───────────▼───────────┐
                    │    ExecutionLayer      │
                    │  Serial / Parallel     │
                    └───────────┬───────────┘
                                │ Block I/O (Gap + MTU)
                    ┌───────────▼───────────┐
                    │   ShadowCore (SoT)    │
                    │ collected_at          │
                    │ updated_at            │
                    │ CommunicationProfile  │
                    │ (纯内存，不落盘)       │
                    └───────────┬───────────┘
                                │ notifySubscribers
         ┌──────────────────────┼──────────────────────┐
         │                      │                      │
   WebSocket              ShadowBridge            VirtualShadow
   (UI 实时)              PushToPipeline
                              │
                    ┌─────────▼─────────┐
                    │   DataPipeline    │
                    └─────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              │               │               │
        EdgeCompute      NorthboundMgr    Storage.values
        (规则触发)       (MQTT/OPC UA)    (历史)

设计约束：

单一写入点：ScanEngine 读、WritePoint 写，均经 ShadowCore。
单一 UI 读出点：REST/WS 读 Shadow；驱动直读仅 Diagnostics API。
Pipeline 只做扇出，不做真源。
Shadow 纯内存：运行时真源不落盘；重启后由 ScanEngine 重新填充，通信画像随采集重建。
升级提示：自旧版升级后，若 runtime.db 体积异常偏大，启动时会自动删除遗留的影子运行时 bucket；执行「压缩运行时库」可回收磁盘占用（见运行时架构 §9）。

6. 分期实施计划

6.1 Q3-A（7 月）— 统一数据面 + 调度可观测【P0】

主题：打通 Shadow → Pipeline，消除 G1 数据面分裂。

编号	任务	交付物	验收标准
A1	Shadow → Pipeline 桥接	`shadow_pipeline_bridge.go` 或在 `WriteShadowDevice` 后扇出	周期采集后 ECM 规则触发、NBM 收到 Publish、values 落库
A2	ScanEngine 状态回写	`executeTaskAsync` 调用 `StateManager.FinalizeCollect`	设备 Online/Offline 与采集成功率一致
A3	清理死代码	删除或归档 `channel_manager.collectDevice`	无第二采集路径；RTT 更新移入 ScanEngine
A4	写入路径规范	设计文档：ScanEngine 直连 Shadow vs ShadowIngress	确定单一写入规范并落地
A5	调度可观测指标	`scan_lag_ms`、`task_overdue_total`、`starvation_rescue_total`	暴露于 `GET /diagnostics/scan-engine` 与 `sla_warnings[]`
A6	集成测试	`shadow_pipeline_integration_test.go`	UI / WS / 规则 / 北向 / DB 四路值与 Quality 一致

A1 实现要点：

// 伪代码：ShadowCore.notifySubscribers 之后或 Subscribe 回调
for pointID, pt := range points {
    pipeline.Push(model.Value{
        ChannelID: channelID,
        DeviceID:  deviceID,
        PointID:   pointID,
        Value:     pt.Value,
        Quality:   pt.Quality,
        TS:        pt.CollectedAt,
    })
}

工业采集软件对齐：Publish Rate 分离（北向 Handler 可独立限频，采集仍全速写 Shadow）。

6.2 Q3-B（8 月）— Scan Class + 块读闭环【P0】

主题：可预测调度 + Modbus/OPC UA 高吞吐 I/O。

编号	任务	交付物	验收标准
B1	Scan Class 模型	`model.Point.scan_class`：`fast`/`normal`/`slow`	同设备 100ms + 1s 两类 Tag 并存
B2	多任务注册	`registerDeviceToScanEngine` 按 Class 分组	每设备每 Class 一个 ScanTask
B3	工业调度模式	设备配置 `degrade_on_failure: false`	失败不拉长 Interval，仅 Quality=Bad
B4	Event-driven 调度	堆顶 `time.After` + 10ms 兜底 tick	CPU 对比报告（万任务场景）
B5	Gap → Modbus 读路径	ExecutionLayer / ModbusExecutor 读前分片	100 离散地址请求数 ↓ ≥30%
B6	MTU → PDU 上限	读分片不超过 `CurrentMTU`	无超帧；画像 MTU 随采集更新
B7	ScanEngine → RTT	Execute 后 `UpdateDeviceRTT` + Shadow 画像	EWMARTT 随采集变化
B8	OPC UA 分批 Read	超 N 点拆分请求	500+ 点设备稳定无超时

Scan Class 默认值：

Class	默认 Interval	典型场景
`fast`	100ms	高速计数、报警量
`normal`	1000ms	常规模拟量
`slow`	10000ms	静态配置、累计量

工业采集软件对齐：Scan Class + Block I/O。

6.3 Q3-C（9 月）— Tag 韧性 + 压测 + Diagnostics 【P1】

主题：工业可用性验证与运维可视。

编号	任务	交付物	验收标准
C1	点位降级框架	`point_degradation_manager.go`	连续 3 次失败 → 降级；指数探测恢复
C2	Tag 级 Quality	ShadowPoint 增加 `degraded` 标记	UI 显示降级状态；降级 Tag 不拖死同批读
C3	万 Tag 压测	`docs/testing/Q3_10k_tag_benchmark_2026Q3.md`	1w Tag @1s · 2h · 内存漂移 <5% · 无 panic
C4	Diagnostics API	`diagnostics_handler.go`	每设备：EWMARTT、MTU、Gap、成功率、调度 lag
C5	UI 画像面板	`DeviceMetricsCard` 扩展	RTT/Gap/成功率曲线（补 Q2 Step-5）
C6	Store & Forward	北向 cache + 南向 history 统一策略	断网 30min 恢复后数据补发验证

点位降级规则：

失败计数 ≥ 3 → 状态 Degraded → 跳过常规 ScanTask 读列表
探测间隔 = base × 2^n（上限 5min）
探测成功 1 次 → 恢复 Normal

工业采集软件对齐：Tag Diagnostics + Store & Forward。

7. Q3 明确不做 / 推迟 Q4

项	原因
CommDriver HAL	收益低于 ScanEngine + 驱动直连
零拷贝 Ring Buffer	非当前瓶颈
Traffic-Aware Heartbeat	依赖 HAL；Q4 评估
Atomic QoS2 全链路	先保证 QoS0 扇出一致
100k 点/秒	Q3 目标 1w Tag；10w 为 Q4

8. 验收标准（Q3 末）

指标	目标值	验证方法
数据一致性	UI / MQTT / 规则 / values 四路一致	A6 集成测试 + 手工 MQTT 订阅
调度 SLA	1s Class：95% 落在 [1s, 1s+100ms]	压测日志 + `scan_lag_ms` 分位
防饿死	任意设备 5min 内 rescue 或成功采集	`starvation_rescue_total` + 注入测试
Modbus 块读	100 离散点请求数 ↓ ≥30%	B5 对比测试
点位降级	故障 Tag 不影响同设备其他 Tag	C1 故障注入
压测稳定性	1w Tag · 2h · 内存漂移 <5%	C3 报告
可观测	每设备可查 RTT/MTU/Gap/成功率	C4 API + C5 UI
规则延迟	扇出后规则触发 <100ms	A6 计时
72h 长跑	无 panic、无 goroutine 泄漏	Q3 末可选加班验收

9. 交付物清单

类型	路径
统一数据面桥接	`internal/core/shadow_bridge.go`
Scan Class 模型	`internal/model/scan_class.go`
调度指标	`internal/core/scan_engine_metrics.go`
点位降级	`internal/core/point_degradation_manager.go`
Diagnostics API	`internal/server/diagnostics_handler.go`
集成测试	`internal/core/shadow_pipeline_integration_test.go`
压测报告	`docs/testing/Q3_10k_tag_benchmark_2026Q3.md`
UI 画像	`ui/src/components/DeviceMetricsCard.vue`
Q3 审查	本文 §11（Q3 末填写）

10. 风险与依赖

风险	概率	影响	缓解
Shadow→Pipeline 双写性能	中	CPU / 延迟	同设备批量 Push；Pipeline 合并窗口
Scan Class 任务膨胀	中	调度开销	每设备每 Class 一任务，非每 Tag
Modbus 双驱动 init 冲突	低	行为不确定	Q3-B 统一 ModbusExecutor
边缘规则风暴	低	CPU	ECM 队列满丢弃 + 规则 debounce
OPC UA 订阅 + 块读并存	中	复杂度	B8 明确：Scan 走 Read，订阅仅做变化推送可选
通信画像重启丢失	低	RTT/MTU 需重探	画像随采集重建；Shadow 不落盘（设计约束）

11. Q3 进度跟踪（Q3 末填写）

计划更新时间：2026-09-30

11.1 任务完成率

阶段	计划项	状态	完成日	备注
Q3-A	A1 Shadow→Pipeline	✅	2026-06-25	`shadow_bridge.go` + `main.go` Attach
Q3-A	A2 状态回写	✅	2026-06-25	`finalizeScanCollect`
Q3-A	A3 死代码清理	✅	2026-06-25	`collectDevice` 已移除
Q3-A	A4 写入规范	✅	2026-06-25	Shadow SoT，`collected_at`/`updated_at`
Q3-A	A5 调度指标	✅	2026-06-28	`scan_engine_metrics.go` + `/api/diagnostics/scan-engine`；新增 `scan_lag_p95_ms`/`scan_lag_max_ms`
Q3-A	A6 集成测试	✅	2026-06-28	`shadow_pipeline_integration_test.go` + `TestScanEngine_ShadowPipelineEndToEnd`
Q3-B	B1 Scan Class	✅	2026-06-25	`model/scan_class.go`
Q3-B	B2 多任务注册	✅	2026-06-25	`scan_engine_compat.go`
Q3-B	B3 工业调度模式	✅	2026-06-25	`degrade_on_failure`
Q3-B	B4 Event-driven	✅	2026-06-25	`nextReadyTime` / wake timer
Q3-B	B5 Gap 块读	✅	2026-06-25	execution → ModbusExecutor
Q3-B	B6 MTU 分片	✅	2026-06-25	Shadow MTU → `batchSize`
Q3-B	B7 RTT 回写	✅	2026-06-25	`executeTaskAsync` → `UpdateDeviceRTT`
Q3-B	B8 OPC UA 分批	✅	2026-06-25	`readDirect` chunk 100 nodes
Q3-C	C1 点位降级	✅	2026-06-25	`point_degradation_manager.go`
Q3-C	C2 Tag Quality	✅	2026-06-25	`ShadowPoint.degraded`
Q3-C	C3 万 Tag 压测	✅	2026-06-28	`q3_10k_tag_benchmark_test.go` + `docs/testing/Q3_10k_tag_benchmark_2026Q3.md`；含 `shadow_core.go` 增量 notify 优化
Q3-C	C4 Diagnostics API	✅	2026-06-25	`diagnostics_handler.go`
Q3-C	C5 UI 画像	✅	2026-06-25	`DeviceMetricsCard` RTT/Gap
Q3-C	C6 Store & Forward	✅	2026-06-25	`store_forward.go` + Pipeline batch
存储	ShadowCore 纯内存	✅	2026-06-30	影子设备运行时真源不落盘

11.2 验收指标实测

指标	目标	实测	通过
数据四路一致	是	集成测试 Shadow→Pipeline→handler；`TestScanEngine_ShadowPipelineEndToEnd`	✅
1s Class P95 lag	≤100ms	7.37 ms（P95）；`scan_lag_p95_ms`/`scan_lag_max_ms` 可观测	✅
Modbus 请求减少	≥30%	100 点分组测试 ~96%	✅
1w Tag 2h 压测	通过	60s CI：7000/7000、内存漂移 4.17%、无 panic；2h 待目标硬件 `Q3_BENCH_DURATION=7200`（可选）	✅

11.3 Q4 入口建议

基于 Q3 万 Tag 压测（mock 驱动 ~11.6k points/s）与 CI 60s 窗口实测：

2h / 72h 长跑：在目标 ARM/x86 网关硬件上执行 Q3_BENCH_DURATION=7200 及 72h 可选验收，验证内存与 goroutine 长期稳态。
真实驱动压测：当前为 mockStressDriver 零 I/O 基线；Modbus/OPC UA 真机 10k Tag 需单独压测报告。
100k points/s 吞吐：推迟 Q4；当前 mock 基线 ~11.6k points/s，需块读 + Pipeline 合并后逐步逼近。
北向 Publish Rate 批合并（可选）：高频场景下 Pipeline 合并窗口进一步 batch，采集全写 Shadow、北向独立限频。

12. 关键源码索引

Concern	Path
启动 / Shadow 绑定	`cmd/main.go`
采集调度	`internal/core/scan_engine.go`
执行层	`internal/core/execution_layer.go`
影子 / 桥接	`internal/core/shadow_core.go`, `shadow_bridge.go`
运行时存储	`internal/storage/boltdb.go`
管道	`internal/core/pipeline.go`
画像 RTT/MTU/Gap	`internal/core/rtt_manager.go`, `mtu_manager.go`, `gap_optimizer.go`
设备适配	`internal/core/device_adapter.go`
通道管理	`internal/core/channel_manager.go`
边缘规则	`internal/core/edge_compute_manager.go`
北向	`internal/core/northbound_manager.go`
Modbus 驱动	`internal/driver/modbus/modbus.go`
OPC UA	`internal/driver/opcua/opcua.go`
Q2 审查详情	Q2 文档 §12

*文档版本 V1.0

2026-06-25 初版

维护：架构组*